Setting Authentication Parameters

Supported Authentication Types

Requirements

How Authentication Support Works

Authentication Support Details

Authentication Table

Checking Authentication Data

Wrong Login Credentials Error

LoadComplete supports the most popular authentication types:

• Basic
• Certificate
• Digest
• Form-based
• Kerberos
• Negotiate
• NTLM (ver. 2.0)
• OAuth

LoadComplete simulates operations with the supported authentication types through the Security Support Provider Interface (SSPI). In order for LoadComplete to be able to reproduce load tests successfully, the appropriate SSPI support components must be installed in the operating system.

Typically, when a client tries to access restricted resources, the server denies access if no proper authentication data is specified. To get access, the client sends a request with authentication data (usually, it is a name/password pair). The server verifies the credentials and either grants access to the requested resource or denies it.

During scenario recording, LoadComplete detects this data exchange and records it in the same way it records regular requests and responses:

Depending on the authentication type (see below), LoadComplete does one of the following:

• It records the credentials as part of a scenario (in a plain or encoded format, depending on the authentication type):

  

• It does not capture the credentials, nor does it store them in the recorded scenario. Instead, it adds the server providing the restricted resources to the Authentication table of your project. You specify your credentials for the server manually in the table so that LoadComplete can use them during simulation:

  

During traffic simulation, LoadComplete automatically detects any authentication challenges coming from the tested web server and sends the credentials provided during the recording or specified in your project. If the credentials are valid and access is granted, LoadComplete will get and validate the server response:

We recommend that you start recording before sending any requests to your tested web server and before sending any authentication data. If you start recording after the authentication data is provided, during simulation, the needed data will not be sent, and your tested web server will deny access to the requested resources. If the needed authentication data is specified in the Authentication table of your project, LoadComplete will try to use it to get access to the resources (see Automatic Authentication). If it fails to do that, for example, if no credentials are specified or if they are invalid, your simulation will fail.

For details on how each authentication type is supported and how you specify the credentials to be used during simulation, see the sections below.

Some authentication types require that the user specify the user name and password. Other types rely on other data like a Windows user account or a security certificate installed on the user computer.

To configure a connection for certain authentication types, you may need to specify user credentials in the Authentication editor of your project (see below). For other authentication types, you can modify the user name and password by editing the recorded traffic in the scenario editor. For some other types, you need to configure the computer or computers where you run tests. See below for details.

Basic

Certificate

Digest

Form-Based Authentication (FBA)

Kerberos

This authentication type uses the Key Distribution Center (KDC) service to provide both the client and the server with session keys. It uses the session keys to encrypt and decrypt data transferred between the client and the server.

During scenario recording, LoadComplete detects web servers that use Kerberos authentication and creates an item for them in the Authentication editor. You can then change the user name and password in this editor. When LoadComplete reproduces the recorded traffic to web servers that support Kerberos authentication, it uses the user name and password specified in the Authentication editor.

Note:

LoadComplete can neither record, nor reproduce authorization requests for web servers that use Kerberos Authentication with Extended Protection for Authentication enabled. The Extended Protection should be disabled on such a server if you want to authorize on it when recording or reproducing traffic. Note, however, that this will impair your server security.

Negotiate

NTLM

A secure authentication type. It hashes the user name and password before sending them through the network. This type of authentication does not require a user name or password. Instead, it uses the information about the current Windows user account registered on the client computer. Currently, LoadComplete supports NTLM ver. 2.0.

When LoadComplete reproduces the recorded traffic to web servers that support NTLM authentication, it uses the user name and password specified in the Authentication editor. During scenario recording, LoadComplete detects web servers that use NTLM authentication and creates an item for them in the Authentication editor. If needed, you can then change the user name and password in this editor.

Make sure to enter the user name and password of the Windows account you will use to run LoadComplete or its Remote Agent (if you run tests on remote computers).

OAuth

In this table, you can manage the authentication parameters the scenarios of your project use. Before sending an authentication request during the test run, LoadComplete will check the name or IP address of the target server and will retrieve the appropriate user name and password from the table to use them in the the request.

To open the table, double-click the Authentication node in the Project Explorer panel. (If the panel is hidden, choose View > Project Explorer from LoadComplete main menu to make it visible):

The table has the following columns:

Important notes:

• Each row in the table corresponds to one server. This means you can use only one login-password pair for a server. If you need to simulate different user logins, specify variables in the Login and Password cells. Put the @ character before the variable name. For example, @user-name-variable.

• Specify the server value that exactly matches the server name or address LoadComplete uses in its work. Otherwise, LoadComplete will be unable to use the provided authentication information. For example, testserver.domain.com and testserver are two different computer names, so, you cannot specify testserver.domain.com if the server’s computer name is testserver.

  To find the correct name, open your scenario for editing and look at the Host List panel. Specify the server name as it is displayed in this panel (minus the colon and port number, of course). To verify you have specified the server name correctly, check if the Summary page of the top-level Scenario item displays an error or not. See below.

• If the tested web server uses the Negotiate authentication and the Authentication table does not have an entry for that server (this may be, for instance, if server is specified incorrectly), LoadComplete will use the login and password of the user account that it is running under.

Working With the Editor

To add a new account

To add a new accountTo add a new account

1. Right-click somewhere in the Authentication table and choose New Item from the context menu.

   This will add a new row to the table.

2. Change the cell values to specify the needed settings.

To add an account based on an existing account

To add an account based on an existing accountTo add an account based on an existing account

1. Right-click an existing account in the Authentication table and choose Copy or Cut from the context menu.

2. Right-click somewhere in the table and choose Paste from the context menu.

Note:

Since the table does not allow entering several credentials for the same server, it will automatically change the server name when you paste the data.

To modify account information

To modify account informationTo modify account information

1. Click the needed cell to select it and then press F2, or click the cell twice (not a double-click). This will open the in-place editor.

2. Enter the needed data in the editor.

3. Press Enter to confirm the changes and to close the in-place editor, or press Esc to cancel the changes.

To delete a user account

To delete a user accountTo delete a user account

• Right-click the account you want to delete and choose Delete from the context menu.

To save or discard changes

To save or discard changesTo save or discard changes

To save the changes you have made in the table, select File > Save from the main menu of LoadComplete.

To close the table and discard the changes, close the table and answer “No” when asked if you want to save the changes.

To check if you specified the authentication data correctly:

1. Open your scenario for editing.

2. In the scenario editor, select the top-level Scenario node and switch to the Summary page.

3. If your scenario has a server that requires authentication and for which you have not specified authentication data, the Summary page will report the “Failed to find credentials for Server_Name” error.

4. Open the Authentication editor and add the correct web server name.

A possible cause of the “Failed to find credentials...” error is a misprinted or incorrect server name in the Authentication settings. When configuring the settings, specify the server as it is specified in the Host List panel of the scenario editor (ignore the port, of course).

When LoadComplete fails to find authentication information for a server in the Authentication table, it posts an error message to the test log informing you about the problem:

Unable to find credentials for the "HOST_NAME" host which the tested server requested. These data are not specified in the Authentication Information table…

To solve the problem, specify the correct server name, user name and password in the Authentication table.